Traditionally, application program interface (API) usage has been monitored for various purposes. For example, many times intrusion prevention systems monitor API usage to detect malicious activity. However, conventional techniques for monitoring API usage have generally exhibited various limitations, particularly where such techniques intercept API invocations for monitoring purposes. Just by way of example, during processing of an intercepted API invocation, a secondary API may be invoked from within the interception. Invocation of such secondary API from within the interception of the first API may be associated with unwanted results.
In some exemplary situations, a resource required for completion of the secondary API may be unavailable until the first API completes, thus resulting in deadlock and/or livelock of an associated process. In other exemplary situations, unnecessary serialization may occur due to the serialization of resources required by the secondary API, further resulting in a delay in the completion of the first API. In yet other exemplary situations, unintended effects of the usage of the secondary API from within the context of a thread invoking the first API may occur, such as manipulation of thread-specific data internally managed by the secondary API. Further, many APIs that may be invoked as a secondary API may not necessarily support a timeout, thereby perpetually intercepting the first API.
There is thus a need for overcoming these and/or other issues associated with the prior art.